🤖 Pull request artifacts

empty string

considering the flood expire time of 10 minutes, 3 min is very reasonable. maybe could even bump it up to 5.

Why not the whole 10?

I don't think we should set it too high, it's a bit annoying for first-time users if you have to wait a while before a node shows up in your node list if you start up one after the first sent out its initial NodeInfo.

Survey time? 😄
Thumbs up this comment for 3 minutes
Thumbs down this comment for 5 minutes

I'm fine with either 3 or 5 minutes. no real preference.

something else we should consider is always sending NodeInfo to NODENUM_BROADCAST, instead of DMs.

I'm fine with either 3 or 5 minutes. no real preference.

firmware/src/mesh/MeshService.cpp

Lines 92 to 93 in 13cc1b0

	LOG_INFO("Heard a node on channel %d we don't know, sending NodeInfo and asking for a response.\n", mp->channel);
	nodeInfoModule->sendOurNodeInfo(mp->from, true, mp->channel);

something else we should consider is always sending NodeInfo to NODENUM_BROADCAST, instead of DMs.

Yeah I fixed this the other day because it was making it seem like some nodes were on the wrong channel

I'm also fine with either 3 or 5 min.

In the specific case Andre linked I think it makes sense to send the NodeInfo as DM, because we request a response from the unknown node, we don't want everyone to respond.

In the specific case Andre linked I think it makes sense to send the NodeInfo as DM, because we request a response from the unknown node, we don't want everyone to respond.

for sure, we would send to NODENUM_BROADCAST and wantReplies false. unless we really need a response. otherwise as a DM we would only reply to one single node every 3-5 minutes.

Yeah, makes sense to only set lastSentToMesh when it's a broadcast.

Could we make NodeInfo DMs (or maybe they already are and I missed it) read promiscuously as long as we can decode? That way, if I send a DM to interrogate NodeInfo only for a specific destination node that I don't know yet, any observers still would also get the benefit of observing that (but not rebroadcasting).

Could we make NodeInfo DMs (or maybe they already are and I missed it) read promiscuously as long as we can decode? That way, if I send a DM to interrogate NodeInfo only for a specific destination node that I don't know yet, any observers still would also get the benefit of observing that (but not rebroadcasting).

Yeah I was already able to decode them, I just was not expecting a dm

Could we make NodeInfo DMs (or maybe they already are and I missed it) read promiscuously as long as we can decode?

I like that. we could finally use sniffReceived().